基于 BLE 5.1 协议 Core Spec。

目录

1、分类

2、Advertising Events

2.1、Interval

2.2、Extended Advertising Event

2.3、Periodic Advertising Event

3、Connectable and scannable undirected event type

4、Connectable directed event type

4.1、Legacy

4.1.1、Low duty cycle connectable directed advertising

4.1.2、High duty cycle connectable directed advertising

4.2、Extended

5、Scannable undirected event type

5.1、Legacy

5.2、Extended

6、Non-connectable and non-scannable undirected event type

6.1、Legacy

6.2、Extended

7、Connectable undirected event type

8、Scannable directed event type

8、Non-connectable and non-scannable directed event type

9、总结

本章内容可能较多，不知道会不会引起身体极度不适。请做好耐心看完的准备。Let's go ！

好了，在前面的章节介绍完了 Advertising、Scanning、和 Initiating 的数据包，前提工作准备 Ready！（就像魔兽世界，到了满级，才算是一个开始）

前面章节回顾：

BLE（5）—— 广播态数据包组成（Advertising Packets PDUs）

BLE（6）—— 扫描态数据包组成（Scanning Packets PDUs）

BLE（7）—— 发起态数据包组成（ Initiating Packets PDUs）

有了上面的 packets 描述，现在，我们有实力去看相关的 handshake 和 Timing 了。

使用 Advertising 状态下的各种包，可以组成各种不一样的 Advertising 的业务形态，这里我们统称 Advertising 的业务为 Advertising Event。

根据 Advertising Event 的基本属性（是否可连接，是否可扫描，是否定向），我们将其分为几大类：

• a connectable and scannable undirected event ------------------ 可连接、可扫描、非定向

• a connectable undirected event --------------------------------------- 可连接，不可扫描、非定向

• a connectable directed event ------------------------------------------ 可连接，不可扫描，定向

• a non-connectable and non-scannable undirected event ------ 不可连接、不可扫描、非定向

• a non-connectable and non-scannable directed event ---------- 不可连接、不可扫描、定向

• a scannable undirected event ------------------------------------------ 不可连接、可扫描、非定向

• a scannable directed event --------------------------------------------- 不可连接、可扫描、定向

蓝牙 BLE 业务都是周期性事件，Advertising 也不例外，一个 Advertising Event 的被定义成为，一次 ADV 业务，对于 Legacy 来说，就是在 37、38、39 上个各发出一个 ADV 包（有交互，就交互），对于 Extend ADV 来说，是完成 37、38、39 上个各发出一个 EXT ADV 包后，在第二通道上发出其对应的包的全过程（有交互，就交互）。

既然蓝牙 BLE 是周期性业务，那么周期性业务就必然存在一个参数，就是多久发生一次业务，我们管这个参数叫 Interval（间隔），Advertising 也不例外。那么我们看下面的图：

这里，一个 ADV Interval 是我们的间隔，但是实际上，每两个的 Advertising Event 之间的实际时间呢：

T_advEvent = advInterval + advDelay

这个 advDelay 是一个 10ms 的伪随机数。

对于 Legacy 的 Advertising Event 来说，和 2.1 中一致，这里就没有单独说了。对于 Extended Advertising 的行为是，首先在 Primary Channel 上发送一个 EXT ADV 包，然后需要的话，在 Secondary Channel 上发送 AUX 包。如果有更多的数据，则接着发送 CHAIN 包，空中的时序类似：

可以看到，先在 37、38、39 上发送了 EXT_ADV_IND 后，在发送 AUX 包。AUX 包的位置有 EXT_ADV_IND 中的 AuxPtr 域进行描述。当然，这里我们看到的是比较理想的情况，也有 AuxPtr 很远的情况，导致重叠：

Core Spec 对 Extended Advertising Event 的定义是，发送了完整的 EXT 包后，并且完成了相关的 AUX  包（或者 CHAIN 包）后，才算完成了一个 Extended Advertising Event。

周期性广播，是 BLE 5.0 新增的部分，用于描述有给定的周期发送数据的广播类型，这种广播具有 SYNC 的含义，能够被支持 BLE 5.0 以上的设备建立 SYNC ，一直监听周期性广播的内容（ISO 部分）。它的时序依然是在主通道上，由 ADV_EXT_IND 引出，第二通道上跟着 AUX_ADV_IND，这个包中含 AuxPtr，后面描述了 AUX_SYNC_IND 包的位置。这个 AUX_SYNC_IND 包就是周期性广播的关键，用于承载数据。（当然，数据很多的时候，超过了 251 Bytes，继续跟 CHAIN 包）：

两个 AUX_SYNC_IND 之间，称之为 Periodic Adv 的 Interval。对端根据这个 Interval 建立同步的监听。

那么有的小伙伴有问题了，是不是周期性广播建立后， ADV_EXT_IND 就没用了呢？只发 AUX_SYNC_IND 就好了吧？答案显然不是，因为只有完全听到 EXT 包的 Scanner，才能够继续索引，并建立起周期性的监听。如果没有了前面包的引导，那后面的 Scanner 也无法加入进来了。

这种可连接，可扫描，不定向的广播，只有一种格式，就是 ADV_IND 。它在空中发送，有时序的要求，37、38、39发送完，算一组 ADV 完成，也就是完成了一个 Event。每两个包之间的间隔是 10ms 以内：

既然是 scannable 的，那么它就能够与 Scanner 进行交互，交互的过程是，当 Scanner 在一样的信道上扫描到了这个包（Scanner 会在 37 上开窗扫描，一会又在 38 上开窗扫描，一会又在 39 上开窗扫描），那么 Scanner 就会发送 SCAN_REQ，如果 Advertising 端收到了这个 SCAN_REQ，就会回复 SCAN_RSP。

图中还有一个参数需要注意：T_IFS，这个参数 Spec 要求，为 T_IFS=150us。

还比如：

当然，这个包，也是 Connectable，Connectable体现在，对端发起态的时候，在同样的信道上扫描到了你的 ADV_IND，则立马发送 CONNECT_IND，申请进入连接，此刻的连接没有握手：

T_IFS，这个参数 Spec 要求，为 T_IFS=150us

那么问题来了，万一 Advertising 那边运气不好，正好没收到 CONNECT_IND 咋办，那么 Advertising 这边就进入不了连接状态的 Slave 了，发起态那端自己以为开始连接了，便兴冲冲的做起了 Master。这里 Spec 规定，建立连接初期，6 个 Interval 没有包交互，那么视为连接建立失败，Master 也只有垂头丧气。

看名字就知道，这个是可连接，不可扫描，定向的 Advertising。它分为两种，Legacy 的和 Extended 的。从名字就知道，这种类型的 ADV 完全是冲着指定的设备发起广播，并求成为 Slave ，让对方连接的（我是黄忠，心里很慌，请周瑜打我）。

经典的，也就是 BLE 5.0 之前的（为了兼容）使用的是 ADV_DIRECT_IND 这包来代表此类型。它只会在 primary 通道上发送。仅仅是为了建立指定连接。这种包中，包含的期望和对方连接的 Target Address。

经典的定向广播，又分为两类：

Low duty cycle connectable directed advertising

High duty cycle connectable directed advertising

Low duty 是相对于 High duty 的，其实就是正常的发送定向广播而已，没什么特别的：

由于他是不可扫描的，所以不会引起对方发 SCAN_REQ（即便是发了，也不管）。只会和 CONNECT_IND 交互：

High duty 用于快速建立连接使用，如何个快呢？缩短发送包的时间呗。

Core Spec 规定，这种类型，同信道的两个包之间的间隔必须小于等于 3.75ms，同时在 1.28s 以内，必须退出这种模式：

一个字，就是快。

这种包呢，可以使用 Extended 来描述了，具体的做法当然是套路，先由 ADV_EXT_IND 在第一通道上进行引出，接着在  secondary 上使用 AUX_ADV_IND 包对其进行描述。

当然，这种包是非扫描的，所以，只会理会连接。

图中的 Timing 的 T_MAFS 的含义是 Minimum AUX Frame Space，定义为 300us。

Sadv_idx=(x) 指的是，在 ADV_EXT_IND 中指定的 secondary channel，具体是哪一个 channel。

当然，如果正巧被想连接你的发起态的扫描到，它会发起交互，对端发起 AUX_CONNECT_REQ，本段回复 AUX_CONNECT_RSP，此刻开始准备建立连接：

注意：ADV_EXT 包在可以在 1M 上发送，也可以在 Coded PHY 上发送，不能再 2M 上发送

看名字就知道，这个是不连接，可扫描，不定向的 Advertising。它分为两种，Legacy 的和 Extended 的。从名字就知道，这种类型的 ADV 只是为了让对方进行扫描的交互。

经典的，也就是 BLE 5.0 之前的（为了兼容）使用的是 ADV_SCAN_IND 这包来代表此类型。它只会在 primary 通道上发送。仅仅是为了让 Scanner 方进行交互。完全不会理会 CONNECT_IND 的请求。

当 Scanner 在同一个通道上扫描到了这种包，那么会发送 SCAN_REQ 包，本端回复 SCAN_RSP，完成交互：

这种包呢，可以使用 Extended 来描述了，具体的做法当然还是是套路，先由 ADV_EXT_IND 在第一通道上进行引出，接着在  secondary 上使用 AUX_ADV_IND 包对其进行描述。

交互依然需要满足 Core Spec 的时序，这里不在多说了：

这种是不可连接不可扫描，不定向的，也就是对着天空呐喊的包，不理任何的交互。过程不再多说，直接上图：

这里呢，需要注意，这种呐喊的包，可能会携带很多数据，所以也可能出现携带 CHAIN 包的可能：

注意：具体能携带多少 CHAIN ，取决于硬件能力。

这种是可连接，不可扫描，不定向的，在 Legacy 时代，没有这种，所以就不需要进行兼容了，只有 Extended 支持：

这种是定向的可扫描，不可连接的，在 Legacy 时代，没有这种，所以就不需要进行兼容了，只有 Extended 支持：

对比 Non-connectable and non-scannable undirected event type 来说，这种是定向的而已，也就是给指定的家伙发送广播数据，不带任何交互，所以时序和 Non-connectable and non-scannable undirected event type 完全一样，这里不再说明。

本章讲解了 Core Spec 5.1 的 Advertising 基本上所有的内容，时序和交互。